1. Field of the Invention
This invention relates to the field of computer-based pricing of products.
2. Background Art
Many business enterprises use field sales representatives to initiate, negotiate, and consummate sales transactions with customers. These sales representatives compete with sales representatives from other business enterprises. Sales representatives would prefer to conclude the sales transaction as completely as possible while meeting with the customer. However, it is often not possible to provide timely pricing information to potential customers at the time of the transaction.
As is explained below, there are large amounts of data that must be stored and used to provide accurate pricing for sales transactions. As a result, many companies maintain pricing information in a large central database. Sales representatives must access the database at the home office remotely through network access or by communicating with another person at the home office. The sales representative provides product information as input and receives pricing data as output. The sales representative then communicates this pricing information to the potential customer, often days after the sales meeting occurred. A delay in providing such critical data as pricing to a potential client can be fatal to the transaction, reducing sales.
The large amounts of data required to provide accurate pricing is understood by describing the factors that go into pricing. For many enterprises pricing is typically performed on a customer by customer basis. That is, for a particular product, each customer gets a price that is different from the price offered to other customers (in the present application the term “product” is used generically to refer to tangible products as well as intangible products, such as services). The difference in price for a particular product is a function of numerous factors. The type of product (e.g., hardware, software, or a particular service), the size of the customer, the type of customer organization (e.g., a wholesaler, distributor, or value added reseller), and the customer's geographic location are only a few of many factors that are used to determine a price recommendation for a sales representative.
Assuming that each product is sold at a unique price to a particular purchasing organization (the term “purchasing organization” refers to a single person as well as to purchasing entities such as companies and the like), conventional price determination methods tabulate the price for each product sold to a certain purchasing organization into a price table. For example, if the selling organization has ten thousand different products and there are ten thousand different purchasers, the price table would have one hundred million (i.e., ten thousand multiplied by ten thousand) entries.
Each product may have several attributes that contribute to pricing differential. The weight or size of a product could increase its base shipping cost. The product may be priced differently when it is sold separately instead of as part of a system. If there are ten possible attributes for the same product, the price table described above would have one billion entries. Further, for each product there are usually various adjustments to the basic price. For example, there are usually applicable state and local taxes, actual shipping charges, currency conversions, and a number of possible discounts. If there are ten different types of price adjustments for the same product for a given customer, the size of the table would grow to ten billion entries.
Each category of possible price adjustments has its own sub-adjustments. For example, the adjustment category of discounts includes different types of discounts (i.e. sub-adjustments). The different types of discounts can be a volume discount a general purchase agreement discount, a time-limited discount effective for purchases within a certain date range, an initial offer discount, and so forth. If there are ten different types of discounts for each product or customer, the size of the price table would grow to one hundred billion entries.
In the prior art, a large mainframe computer database contains the price table (“Mainframe computer” refers to any computer with a large database). The customer order is entered in a central billing and financing system within the mainframe computer. The mainframe computer then performs the pricing calculation according to the price tables stored in the database.
The following discussion provides a specific example of various tables used in the conventional pricing system discussed above. FIG. 1 shows an example of a basic price table. Each row in the table designates a potential customer that the product would be sold to, and each column designates the product will be sold, and the table entry corresponding to the basic unadjusted price for the product. In the example of FIG. 1, a 486/33 CPU is sold to Adam at a price of $40, a 486/50 CPU is sold to Adam at a price of $60 and a 486/66 CPU is sold to Adam at a price of $80. A 486/33 CPU is sold to Bob at a price of $42, a 486/50 CPU is sold to Bob at $58, and a 486/66 CPU is sold to Bob at $72. Thus, as the basic price table of FIG. 1 indicates, each particular product is sold to each customer at a price that is different from the price that the same product is sold to another customer.
According to the prior art, in addition to the basic price table of FIG. 1, various other tables must be stored and maintained in the mainframe database. For example, FIG. 2 shows a volume discount table that corresponds to the basic price table of FIG. 1. Thus, the price $40 would be reduced by a discount of 10% if Adam purchases 486/33 CPU's in volume. Thus, Adam can purchase each 486/33 CPU at a volume-discounted price of $40 * (1−(10/100)), i.e. at $36, as compared with the original price $40. Similarly, a volume discount of 12% corresponds to the original price $60, and a volume discount of 14% corresponds to the original price of $80, and so forth.
A pricing application called R3 made by SAP has the prior art disadvantages explained above. For example, R3 requires a number of price adjustment tables and a number of database queries to retrieve applicable price adjustments. Likewise, an order entry application made by Oracle has a similar shortcoming in that a number of database queries are required to retrieve various price adjustments from a large number of price adjustment tables.
The prior art has attempted to provide more responsive pricing systems by providing sales representatives with price tables on portable computers that can be looked up during a sales transaction. However, current portable computers do not have the storage capacity for all of the price tables that are stored on the central database. As a result, the pricing generated by the portable computers may not be reliable, potentially costing the selling company money when the prices are two low, and potentially causing lost sales opportunities when the prices generated are too high.